Skip to content

Add eidetic remember/recall memory skills#1

Merged
OriNachum merged 1 commit into
mainfrom
rollout/eidetic-memory
Jun 23, 2026
Merged

Add eidetic remember/recall memory skills#1
OriNachum merged 1 commit into
mainfrom
rollout/eidetic-memory

Conversation

@OriNachum

Copy link
Copy Markdown
Contributor

Vendors eidetic-cli's first-party remember + recall memory skills into this repo's .claude/skills/ kit (cite-don't-import), giving this agent a shared, persistent memory surface (~/.eidetic/memory) that Claude and the colleague backend both read and write.

  • remembereidetic remember: idempotent upsert of one JSON record or an NDJSON batch on stdin (dedup by id + content hash).
  • recalleidetic recall: four search modes (exact / approximate / keyword / hybrid), each hit carrying text, full provenance metadata, a relevance score, and a freshness signal.

The .sh wrappers are byte-verbatim from eidetic-cli (their first-party origin); this repo's SKILL.md scope examples are localized to its own nick. Version bumped + CHANGELOG updated per the AgentCulture rule. Runtime dep: the eidetic CLI on PATH (else a local eidetic-cli checkout + uv).

Propagated by rollout-cli's eidetic-memory recipe (origin: agentculture/eidetic-cli). Squash-merge at your discretion.

🤖 Generated with Claude Code

  • rollout-cli (Claude)

- **Vendored the `remember` + `recall` memory skills from eidetic-cli**
  (cite-don't-import) — the write/read halves of eidetic's shared
  `~/.eidetic/memory` surface, so this agent (Claude and its colleague backend)
  can persist facts across sessions and recall them later, sharing one store.
  `remember` drives `eidetic remember` (idempotent upsert of one JSON record or
  an NDJSON batch on stdin, dedup by id + content hash); `recall` drives
  `eidetic recall` with four search modes — exact / approximate / keyword /
  hybrid — each hit carrying text, full provenance metadata, a relevance score,
  and a freshness signal. The `.sh` wrappers are byte-verbatim from eidetic-cli
  (their first-party origin); each `SKILL.md` is localized only in the
  illustrative `--scope <nick>` examples (Provenance keeps "First-party to
  eidetic-cli"). Both default to this agent's PRIVATE scope, reading the suffix
  from `culture.yaml`. Runtime dep: the `eidetic` CLI on PATH (else a local
  eidetic-cli checkout with `uv`). Propagated by rollout-cli's `eidetic-memory`
  recipe.
@qodo-code-review

Copy link
Copy Markdown

CI Feedback 🧐

A test triggered by this PR failed. Here is an AI-generated analysis of the failure:

Action: test-publish

Failed stage: Build and publish to TestPyPI [❌]

Failed test name: ""

Failure summary:

The action failed during the uv publish step because PyPI Trusted Publishing could not issue an API
token.
- The publish request to TestPyPI returned 422 Unprocessable Entity with invalid-publisher:
“valid token, but no corresponding publisher (Publisher with matching claims was not found)”.
- The
OIDC token claims shown in the log (notably repository: agentculture/refactor-cli, environment:
testpypi, and job_workflow_ref:
agentculture/refactor-cli/.github/workflows/publish.yml@refs/pull/1/merge) did not match any Trusted
Publisher configured in TestPyPI.
- As a result, uv publish --trusted-publishing always exited with
code 2 and the workflow stopped.

Relevant error logs:
1:  ##[group]Runner Image Provisioner
2:  Hosted Compute Agent
...

194:  ##[endgroup]
195:  Publishing 0.3.0.dev3 to TestPyPI
196:  ##[group]Run uv build
197:  �[36;1muv build�[0m
198:  �[36;1muv publish --publish-url https://test.pypi.org/legacy/ --trusted-publishing always --check-url https://test.pypi.org/simple/�[0m
199:  shell: /usr/bin/bash -e {0}
200:  env:
201:  UV_CACHE_DIR: /home/runner/work/_temp/setup-uv-cache
202:  DEV_VERSION: 0.3.0.dev3
203:  ##[endgroup]
204:  Building source distribution...
205:  Building wheel from source distribution...
206:  Successfully built dist/refactor_cli-0.3.0.dev3.tar.gz
207:  Successfully built dist/refactor_cli-0.3.0.dev3-py3-none-any.whl
208:  Publishing 2 files to https://test.pypi.org/legacy/
209:  error: Failed to obtain token for trusted publishing
210:  Caused by: Server returned error code 422 Unprocessable Entity, is trusted publishing correctly configured?
211:  Response: {"errors":[{"code":"invalid-publisher","description":"valid token, but no corresponding publisher (Publisher with matching claims was not found)"}],"message":"Token request failed"}
212:  Token claims, which must match the publisher configuration: GitHub(
213:  GitHubTokenClaims {
214:  sub: "repo:agentculture/refactor-cli:environment:testpypi",
215:  repository: "agentculture/refactor-cli",
216:  repository_owner: "agentculture",
217:  repository_owner_id: "277824871",
218:  job_workflow_ref: "agentculture/refactor-cli/.github/workflows/publish.yml@refs/pull/1/merge",
219:  ref: "refs/pull/1/merge",
220:  environment: Some(
221:  "testpypi",
222:  ),
223:  },
224:  )
225:  ##[error]Process completed with exit code 2.
226:  ##[group]Run echo "::notice::Test with: uv tool install --index-url https://test.pypi.org/simple/ --index-strategy unsafe-best-match refactor-cli==${DEV_VERSION}"

@sonarqubecloud

Copy link
Copy Markdown

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Vendor eidetic-cli remember/recall skills for persistent shared memory
✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

Description

• Vendor eidetic-cli /remember and /recall skills for shared ~/.eidetic/memory storage.
• Add portable wrappers that default to repo-scoped private memory via culture.yaml suffix.
• Bump version to 0.3.0 and document the addition in CHANGELOG.
Diagram

graph TD
  A(("Claude + colleague")) --> R["remember.sh"] --> E{{"eidetic CLI"}} --> M[("~/.eidetic/memory")]
  A(("Claude + colleague")) --> C["recall.sh"] --> E{{"eidetic CLI"}} --> M[("~/.eidetic/memory")]
  Y["culture.yaml"] --> R["remember.sh"] --> E{{"eidetic CLI"}}
  Y["culture.yaml"] --> C["recall.sh"] --> E{{"eidetic CLI"}}
  C["recall.sh"] --> E{{"eidetic CLI"}} --> S{{"Embed server"}}

  subgraph Legend
    direction LR
    _actor(("Agent")) ~~~ _proc["Wrapper script"] ~~~ _ext{{"External CLI/service"}} ~~~ _db[("Store")]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Make eidetic-cli a pinned runtime dependency (no vendoring)
  • ➕ Less duplicated code/docs in this repo
  • ➕ Upstream updates land automatically via dependency bumps
  • ➖ Conflicts with the stated cite-don't-import/vendoring policy
  • ➖ Harder to ensure local scope-default behavior stays consistent across environments
  • ➖ Reviewers must trust upstream changes rather than reviewing the exact shipped skill content
2. Vendor as a git submodule/subtree pointing at eidetic-cli
  • ➕ Keeps provenance and update workflow explicit
  • ➕ Can selectively pull upstream changes with history
  • ➖ Submodules add operational friction for contributors/CI
  • ➖ Still couples runtime behavior to repo layout; wrappers already solve portability without git plumbing

Recommendation: Keep the current vendored-skill approach: it matches the repo’s cite-don’t-import policy, keeps the exact shipped wrappers/docs reviewable, and still cleanly delegates all core behavior to the external eidetic CLI. If update cadence becomes high, consider a subtree workflow, but avoid unpinned upstream runtime drift.

Files changed (6) +599 / -1

Enhancement (2) +279 / -0
recall.shAdd recall.sh wrapper for 'eidetic recall' with default private scope +141/-0

Add recall.sh wrapper for 'eidetic recall' with default private scope

• Adds a portable shell wrapper that resolves the 'eidetic' CLI (PATH first, then 'uv run' in a local eidetic-cli checkout). If '--scope' is not provided, it reads the nearest 'culture.yaml' suffix and injects '--scope <suffix>' plus default '--visibility private' (unless explicitly overridden), and sets default embedding env vars.

.claude/skills/recall/scripts/recall.sh

remember.shAdd remember.sh wrapper for 'eidetic remember' with scope injection +138/-0

Add remember.sh wrapper for 'eidetic remember' with scope injection

• Adds a portable shell wrapper that finds the 'eidetic' CLI and forwards args verbatim to 'eidetic remember'. When '--scope' is not provided, it derives the scope from 'culture.yaml' and defaults visibility to private unless the user passes '--visibility' explicitly.

.claude/skills/remember/scripts/remember.sh

Documentation (3) +319 / -0
SKILL.mdAdd recall skill documentation and usage guidance +181/-0

Add recall skill documentation and usage guidance

• Introduces the '/recall' skill spec describing search modes (exact/approximate/keyword/hybrid), output fields, lifecycle flags, and freshness scoring. Documents that the default query scope/visibility are derived from 'culture.yaml' and that results are provenanced for cited answers.

.claude/skills/recall/SKILL.md

SKILL.mdAdd remember skill documentation and record schema +118/-0

Add remember skill documentation and record schema

• Introduces the '/remember' skill spec describing JSON/NDJSON ingest, idempotent upsert semantics, recommended provenance metadata, and lifecycle linking via 'supersedes'/'sweep'. Documents default private per-repo scope derived from 'culture.yaml' and how to opt into public shared memory.

.claude/skills/remember/SKILL.md

CHANGELOG.mdDocument eidetic memory skills addition in 0.3.0 release notes +20/-0

Document eidetic memory skills addition in 0.3.0 release notes

• Adds a 0.3.0 changelog entry describing the vendored remember/recall skills, shared store location, default scoping behavior, and runtime dependency expectations.

CHANGELOG.md

Other (1) +1 / -1
pyproject.tomlBump project version to 0.3.0 +1/-1

Bump project version to 0.3.0

• Updates the package version from 0.2.0 to 0.3.0 to match the changelog release entry.

pyproject.toml

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (2) 📜 Skill insights (1)

Context used
✅ Compliance rules (platform): 17 rules

Grey Divider


Action required

1. .claude/skills/ directly modified 📘 Rule violation ⚙ Maintainability
Description
This PR adds new vendored skill files under .claude/skills/, which the compliance rule disallows
editing directly (including additions). This should be done via the approved guildmaster re-sync
process instead of changing the vendored skill contents in-repo.
Code

.claude/skills/recall/scripts/recall.sh[R1-7]

+#!/usr/bin/env bash
+# recall.sh — search the shared eidetic memory store (the /recall skill).
+#
+# Thin, portable wrapper around `eidetic recall`. It resolves the CLI, points
+# the embedding modes at the local model-gear embed gear (overridable), and
+# forwards every flag verbatim — so `recall.sh "<query>" --mode hybrid --json`
+# is exactly `eidetic recall "<query>" --mode hybrid --json`.
Evidence
The checklist explicitly requires no additions/deletions/modifications under .claude/skills/. The
diff shows new skill files being added under that directory (e.g., recall.sh).

Rule 920898: Do not directly modify files under .claude/skills/; re-sync vendored skills from guildmaster instead
.claude/skills/recall/scripts/recall.sh[1-7]
.claude/skills/remember/scripts/remember.sh[1-10]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Files under `.claude/skills/` were directly added/modified in this PR, which violates the vendored-skill policy; changes must come from the upstream guildmaster sync process instead.

## Issue Context
This PR introduces new skill files (e.g., `recall.sh`, `remember.sh`, and the associated `SKILL.md`) under `.claude/skills/`.

## Fix Focus Areas
- .claude/skills/recall/scripts/recall.sh[1-7]
- .claude/skills/remember/scripts/remember.sh[1-10]
- .claude/skills/recall/SKILL.md[1-23]
- .claude/skills/remember/SKILL.md[1-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. No alignment-delta check noted 📜 Skill insight ≡ Correctness
Description
This PR touches .claude/skills/ but the provided PR description does not mention running an
alignment-delta check (workflow.sh delta or devex pr delta) or any required sibling follow-ups.
This violates the alignment-delta requirement for changes in .claude/skills/.
Code

.claude/skills/recall/SKILL.md[R1-5]

+---
+name: recall
+type: command
+description: >
+  Search the shared eidetic memory store and get back ranked, provenanced
Evidence
The rule requires an alignment-delta check to be included/documented when .claude/skills/ changes
occur. The diff confirms .claude/skills/ is modified in this PR, triggering the requirement.

.claude/skills/recall/SKILL.md[1-5]
.claude/skills/remember/SKILL.md[1-5]
Skill: cicd

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR modifies `.claude/skills/` but does not document that an alignment-delta check was run, nor any sibling repos needing follow-up PRs.

## Issue Context
Compliance requires documenting the delta check whenever `CLAUDE.md`, `culture.yaml`, or `.claude/skills/` are touched.

## Fix Focus Areas
- .claude/skills/recall/SKILL.md[1-5]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Unreachable uv fallback 🐞 Bug ☼ Reliability
Description
resolve_eidetic() only falls back to uv run --project ... eidetic when an ancestor directory’s
pyproject.toml has name = "eidetic-cli", which is not true for this repo. As a result, if
eidetic isn’t on PATH, these skills will always fail even if uv is installed and an
eidetic-cli checkout exists elsewhere.
Code

.claude/skills/recall/scripts/recall.sh[R18-36]

+resolve_eidetic() {
+    if command -v eidetic >/dev/null 2>&1; then
+        EIDETIC=(eidetic)            # installed console script — the normal case
+        return 0
+    fi
+    # Dev fallback: inside the eidetic-cli checkout, run via uv.
+    local dir
+    dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
+    while [ -n "$dir" ] && [ "$dir" != "/" ]; do
+        if [ -f "$dir/pyproject.toml" ] \
+            && grep -q '^name = "eidetic-cli"' "$dir/pyproject.toml" 2>/dev/null; then
+            if command -v uv >/dev/null 2>&1; then
+                EIDETIC=(uv run --project "$dir" eidetic)
+                return 0
+            fi
+            break
+        fi
+        dir=$(dirname "$dir")
+    done
Evidence
The wrapper’s uv run path is gated on finding an ancestor pyproject.toml whose name is exactly
eidetic-cli; this repo’s pyproject.toml is refactor-cli, so the condition cannot be satisfied
here and the wrapper will hit the “CLI not found” error when eidetic is not on PATH.

.claude/skills/recall/scripts/recall.sh[16-43]
.claude/skills/remember/scripts/remember.sh[23-50]
pyproject.toml[1-4]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolve_eidetic()` can only use the `uv run` fallback when the wrapper is physically inside an `eidetic-cli` checkout (ancestor `pyproject.toml` name match). In this repo, that condition never holds, so the fallback path is effectively dead.

### Issue Context
The PR’s documentation and comments imply the wrapper can resolve either an installed `eidetic` or a local checkout with `uv`, but the current implementation cannot locate a checkout unless it’s an ancestor directory of the script.

### Fix Focus Areas
- .claude/skills/recall/scripts/recall.sh[16-36]
- .claude/skills/remember/scripts/remember.sh[23-42]

### Suggested fix
Add an explicit configuration path for the checkout (e.g., `EIDETIC_CLI_PROJECT_DIR` / `EIDETIC_PROJECT_DIR`) and, when set, prefer `uv run --project "$EIDETIC_CLI_PROJECT_DIR" eidetic` before erroring. Keep the current PATH-first behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. recall.sh no-arg exits 0 📘 Rule violation ≡ Correctness
Description
recall.sh treats a missing required <query> argument as help and exits with status 0. Per the
exit-code standardization rule, missing required arguments should exit with code 1 (user error).
Code

.claude/skills/recall/scripts/recall.sh[R67-71]

+case "${1:-}" in
+    -h | --help | help | "")
+        usage
+        exit 0
+        ;;
Evidence
The compliance rule requires missing required CLI arguments to return exit code 1. The added case
branch matches an empty $1 and exits 0 after printing usage.

Rule 920895: Standardize CLI exit codes
.claude/skills/recall/scripts/recall.sh[67-71]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`recall.sh` exits `0` when invoked with no arguments, even though `<query>` is required; this should be a user error with exit code `1`.

## Issue Context
The repo standardizes CLI exit codes: success=0, user error=1, env/system error=2.

## Fix Focus Areas
- .claude/skills/recall/scripts/recall.sh[67-71]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Suffix parse fails silently 🐞 Bug ⛨ Security
Description
If culture.yaml exists but resolve_scope() fails to extract suffix (format drift / parse
mismatch), the wrappers silently omit --scope and thus skip the intended default `--visibility
private. For remember.sh` this can unexpectedly write into eidetic’s CLI defaults (documented as
default/public), undermining the “private-by-default personal scope” guarantee.
Code

.claude/skills/remember/scripts/remember.sh[R94-132]

+resolve_scope() {
+    local dir suffix=""
+    dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
+    while [ -n "$dir" ] && [ "$dir" != "/" ]; do
+        if [ -f "$dir/culture.yaml" ]; then
+            # Capture only the first non-space token after `suffix:` (so an
+            # inline `# comment` or trailing space can't bleed into the scope),
+            # then strip surrounding quotes only — matching the canonical parser
+            # in .claude/skills/cicd/scripts/_resolve-nick.sh.
+            suffix=$(sed -n \
+                's/^[[:space:]]*-\{0,1\}[[:space:]]*suffix:[[:space:]]*\([^[:space:]]*\).*/\1/p' \
+                "$dir/culture.yaml" | head -n1 | tr -d "\"'")
+            break
+        fi
+        dir=$(dirname "$dir")
+    done
+    printf '%s' "$suffix"
+}
+
+has_flag() {
+    local needle=$1
+    shift
+    local a
+    for a in "$@"; do
+        case "$a" in
+            "$needle" | "$needle"=*) return 0 ;;
+        esac
+    done
+    return 1
+}
+
+SCOPE_ARGS=()
+if ! has_flag --scope "$@"; then
+    EIDETIC_SCOPE=$(resolve_scope)
+    if [ -n "$EIDETIC_SCOPE" ]; then
+        SCOPE_ARGS+=(--scope "$EIDETIC_SCOPE")
+        has_flag --visibility "$@" || SCOPE_ARGS+=(--visibility private)
+    fi
+fi
Evidence
The wrappers only add --visibility private when a non-empty suffix is parsed, and explicitly
document that without culture.yaml they fall back to default/public. They also diverge from the
existing _resolve-nick.sh behavior, which warns on a present-but-unparsable manifest.

.claude/skills/remember/scripts/remember.sh[86-93]
.claude/skills/remember/scripts/remember.sh[94-132]
.claude/skills/cicd/scripts/_resolve-nick.sh[19-40]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
When `culture.yaml` is present but no `suffix` can be parsed, the wrappers continue with empty `SCOPE_ARGS`, which (per the script comments) falls back to eidetic’s CLI defaults. This is silent and can change visibility/scope from the intended private personal scope.

### Issue Context
A similar resolver (`.claude/skills/cicd/scripts/_resolve-nick.sh`) emits a warning when `culture.yaml` exists but no suffix can be extracted. The new wrappers do not warn or fail.

### Fix Focus Areas
- .claude/skills/remember/scripts/remember.sh[94-132]
- .claude/skills/recall/scripts/recall.sh[94-132]

### Suggested fix
Track whether a `culture.yaml` was found; if found but parsed suffix is empty, either:
1) **Fail closed** (exit non-zero with a clear remediation: fix `culture.yaml` or pass explicit `--scope/--visibility`), or
2) Emit a prominent stderr warning at minimum (especially for `recall.sh`).
This prevents accidental fallback to default/public in misconfigured repos.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. Skill provenance docs stale 🐞 Bug ⚙ Maintainability
Description
The PR adds skills sourced from eidetic-cli, but the repo’s provenance docs still state the
.claude/skills/ kit is vendored from guildmaster and the README still claims “11 skills”. This
makes future re-syncs and auditing less deterministic because the new upstream/source isn’t recorded
where the repo expects it.
Code

CHANGELOG.md[R8-26]

+## [0.3.0] - 2026-06-23
+
+### Added
+
+- **Vendored the `remember` + `recall` memory skills from eidetic-cli**
+  (cite-don't-import) — the write/read halves of eidetic's shared
+  `~/.eidetic/memory` surface, so this agent (Claude and its colleague backend)
+  can persist facts across sessions and recall them later, sharing one store.
+  `remember` drives `eidetic remember` (idempotent upsert of one JSON record or
+  an NDJSON batch on stdin, dedup by id + content hash); `recall` drives
+  `eidetic recall` with four search modes — exact / approximate / keyword /
+  hybrid — each hit carrying text, full provenance metadata, a relevance score,
+  and a freshness signal. The `.sh` wrappers are byte-verbatim from eidetic-cli
+  (their first-party origin); each `SKILL.md` is localized only in the
+  illustrative `--scope <nick>` examples (Provenance keeps "First-party to
+  eidetic-cli"). Both default to this agent's PRIVATE scope, reading the suffix
+  from `culture.yaml`. Runtime dep: the `eidetic` CLI on PATH (else a local
+  eidetic-cli checkout with `uv`). Propagated by rollout-cli's `eidetic-memory`
+  recipe.
Evidence
The CHANGELOG explicitly records that remember/recall were vendored from eidetic-cli, while
docs/skill-sources.md still frames .claude/skills/ as guildmaster-sourced and its table doesn’t
list these new skills; README.md still asserts the kit is 11 skills.

CHANGELOG.md[8-26]
docs/skill-sources.md[1-7]
docs/skill-sources.md[23-37]
README.md[7-13]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
New skills (`remember`, `recall`) were added, but the repo’s provenance/index docs weren’t updated to reflect the additional upstream (eidetic-cli) and the new skill count.

### Issue Context
`docs/skill-sources.md` is explicitly used as the deterministic provenance tracker for vendored skills, and `README.md` advertises the skill kit contents.

### Fix Focus Areas
- docs/skill-sources.md[1-37]
- README.md[9-13]
- CHANGELOG.md[8-26]

### Suggested fix
1) Add `remember` and `recall` rows to `docs/skill-sources.md` (upstream/origin: eidetic-cli, notes + last synced date).
2) Update `README.md` to reflect the new skill count and/or note the additional eidetic-cli-sourced skills alongside the guildmaster kit.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

Comment on lines +1 to +7
#!/usr/bin/env bash
# recall.sh — search the shared eidetic memory store (the /recall skill).
#
# Thin, portable wrapper around `eidetic recall`. It resolves the CLI, points
# the embedding modes at the local model-gear embed gear (overridable), and
# forwards every flag verbatim — so `recall.sh "<query>" --mode hybrid --json`
# is exactly `eidetic recall "<query>" --mode hybrid --json`.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. .claude/skills/ directly modified 📘 Rule violation ⚙ Maintainability

This PR adds new vendored skill files under .claude/skills/, which the compliance rule disallows
editing directly (including additions). This should be done via the approved guildmaster re-sync
process instead of changing the vendored skill contents in-repo.
Agent Prompt
## Issue description
Files under `.claude/skills/` were directly added/modified in this PR, which violates the vendored-skill policy; changes must come from the upstream guildmaster sync process instead.

## Issue Context
This PR introduces new skill files (e.g., `recall.sh`, `remember.sh`, and the associated `SKILL.md`) under `.claude/skills/`.

## Fix Focus Areas
- .claude/skills/recall/scripts/recall.sh[1-7]
- .claude/skills/remember/scripts/remember.sh[1-10]
- .claude/skills/recall/SKILL.md[1-23]
- .claude/skills/remember/SKILL.md[1-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +1 to +5
---
name: recall
type: command
description: >
Search the shared eidetic memory store and get back ranked, provenanced

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. No alignment-delta check noted 📜 Skill insight ≡ Correctness

This PR touches .claude/skills/ but the provided PR description does not mention running an
alignment-delta check (workflow.sh delta or devex pr delta) or any required sibling follow-ups.
This violates the alignment-delta requirement for changes in .claude/skills/.
Agent Prompt
## Issue description
The PR modifies `.claude/skills/` but does not document that an alignment-delta check was run, nor any sibling repos needing follow-up PRs.

## Issue Context
Compliance requires documenting the delta check whenever `CLAUDE.md`, `culture.yaml`, or `.claude/skills/` are touched.

## Fix Focus Areas
- .claude/skills/recall/SKILL.md[1-5]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +18 to +36
resolve_eidetic() {
if command -v eidetic >/dev/null 2>&1; then
EIDETIC=(eidetic) # installed console script — the normal case
return 0
fi
# Dev fallback: inside the eidetic-cli checkout, run via uv.
local dir
dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
while [ -n "$dir" ] && [ "$dir" != "/" ]; do
if [ -f "$dir/pyproject.toml" ] \
&& grep -q '^name = "eidetic-cli"' "$dir/pyproject.toml" 2>/dev/null; then
if command -v uv >/dev/null 2>&1; then
EIDETIC=(uv run --project "$dir" eidetic)
return 0
fi
break
fi
dir=$(dirname "$dir")
done

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

4. Unreachable uv fallback 🐞 Bug ☼ Reliability

resolve_eidetic() only falls back to uv run --project ... eidetic when an ancestor directory’s
pyproject.toml has name = "eidetic-cli", which is not true for this repo. As a result, if
eidetic isn’t on PATH, these skills will always fail even if uv is installed and an
eidetic-cli checkout exists elsewhere.
Agent Prompt
### Issue description
`resolve_eidetic()` can only use the `uv run` fallback when the wrapper is physically inside an `eidetic-cli` checkout (ancestor `pyproject.toml` name match). In this repo, that condition never holds, so the fallback path is effectively dead.

### Issue Context
The PR’s documentation and comments imply the wrapper can resolve either an installed `eidetic` or a local checkout with `uv`, but the current implementation cannot locate a checkout unless it’s an ancestor directory of the script.

### Fix Focus Areas
- .claude/skills/recall/scripts/recall.sh[16-36]
- .claude/skills/remember/scripts/remember.sh[23-42]

### Suggested fix
Add an explicit configuration path for the checkout (e.g., `EIDETIC_CLI_PROJECT_DIR` / `EIDETIC_PROJECT_DIR`) and, when set, prefer `uv run --project "$EIDETIC_CLI_PROJECT_DIR" eidetic` before erroring. Keep the current PATH-first behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@OriNachum OriNachum merged commit 52250f8 into main Jun 23, 2026
6 of 8 checks passed
@OriNachum OriNachum deleted the rollout/eidetic-memory branch June 23, 2026 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant